@bnoordhuis What do you think?

The first two commits look okay to me but the last one results in an unpleasant amount of code duplication.

The node headers force the usage of -std=gnu++1y, but C++17 is required for this

A binding.gyp can override that (ditto for -fno-exceptions):

{
  'cflags_cc!': ['-std=gnu++1y'],
  'cflags_cc': ['-std=c++17'],
  'xcode_settings': {
    'CLANG_CXX_LANGUAGE_STANDARD': 'c++17',
  },
  # ..
}

But as to -fno-exceptions, you should probably not override that unless you know exactly what you're doing.

You can use exceptions in add-ons (and some do) but they should never ever escape into code compiled without exception support.

The first two commits look okay to me but the last one results in an unpleasant amount of code duplication.

The problem is that this is the only way to maintain backwards compatibility, i.e. not force users to use C++17.
Of course I could deduplicate the code that hasn't been C++17ified, but I will most probably also modify the other async worker classes.

But as to -fno-exceptions, you should probably not override that unless you know exactly what you're doing.

I think it's always better to throw an exception instead of just calling std::terminate() or silently dropping the error...

As nan is a header only library, it should imho be left to the users to decide whether they want exceptions or not.

I think that, at the moment, if no memory can be allocated (which usually never happens), std::terminate() is called.

But from what I read, it might be worth creating and maintaining a nan-cpp17 fork which includes the new C++17 features and does not compile with C++11.
This is however, going to be a merge-hell, because nan has this mega-header nan.h...

As nan is a header only library, it should imho be left to the users to decide whether they want exceptions or not.

Just to be clear, nan takes no position on the use of exceptions. -fno-exceptions is inherited from node's common.gypi through node-gyp: nodejs/node-gyp#1118

it might be worth creating and maintaining a nan-cpp17 fork which includes the new C++17 features and does not compile with C++11

Speaking for myself (not other maintainers), I have no interest in maintaining such a fork at the moment. I expect that most new add-ons will be written using n-api, not nan.

That's not to discourage you, of course. You're welcome to start that fork.

Speaking for myself (not other maintainers), I have no interest in maintaining such a fork at the moment. I expect that most new add-ons will be written using n-api, not nan.

That's not to discourage you, of course. You're welcome to start that fork.

Of course I'd maintain the C++17 fork, should've mentioned that in the first place!

What I was trying to say is that I would much appreciate if it's possible to modularise the nan.h header a bit so that it's easier for me to maintain the fork (i.e. avoid the "merge-hell")...

I'm open to that if it's not too much maintenance and review work. What plan of attack do you propose?

Perhaps something based on the documentation along with the pre-0.12 / post-0.12 split?